Negotiable instruments, such as checks, are often used as a form of payment. In some situations, checks provided as payment are imaged and processed in order to complete a transaction. For example, handwritten information included in a check is electronically analyzed (e.g., using optical character recognition) in order to identify information about the check, such as an amount of the check. If, however, errors occur when information is identified in a check, the check may not be deposited or processed correctly. For example, if a handwritten “7” on a check is identified as a “1” during optical character recognition or if an optical character recognition application cannot read the long-hand dollar amount in the legal amount received (“LAR”) field of a check, the check may be processed incorrectly.
In remittance processing environments, also known as lockbox environments, a payment stub that accompanies a check payment can be used as a validation point to ensure a correct identification or reading of information from the check, such as the check amount. The payment stub can also be used to automate processing of the check payment and reduce human intervention during the processing procedure.
In some situations, however, a payment is not accompanied with a payment stub or another document specifying payment details, and a payment receiver is forced to use only the handwritten data on a check to process the check. As previously noted, electronically identifying handwritten data included in a check can introduce errors and can increase the need for manual review and correction.
Additionally, payment receivers are often not readily informed as to whether a check that was accepted by the payment receiver was processed properly such that the payment receiver received the promised funds. If a check accepted by a payment receiver cannot be processed properly (e.g., the check is written for an incorrect amount or the check was not authorized correctly), the check is often referred to as a non-compliant item. Currently, the only ways for a payment receiver to determine and/or identify non-compliant items is to either manually match checks to transactions processed by the payment receiver (e.g., reviewing transactions managed by a point of sale (“POS”) system of the payment receiver) or to wait for non-compliant checks to be returned (e.g., from a financial institution). Each of these ways can be time-consuming and can delay the processing of a check.
Furthermore, check processing typically includes multiple manual operations. For example, checks presented at one or more POS devices are collected by an individual. The individual must then order the checks according to their receipt at a POS device and arrange the checks so that each check is positioned in the same orientation. In most situations, an individual (e.g., a store manager) routinely collects the checks and brings the checks to a secure area for further processing. Once the checks have been manually processed, they are stored until ready for further processing. When the process is to continue, the batch of checks is submitted to a document processing machine that images the checks.